I guess this PR is to be able to test the ibc middleware that will convert cosmos msgs to ethermint msgs?

would it be possible to write an ADR for the design? @yihuang

I guess this PR itself is just try go-relayer in integration test, so it'll be more convenient for @mmsqe to further experiment using the golang relayer

yes I understand that this PR is only to integrate with the go-relayer but I just using this opportunity to raise the need for an ADR before we are getting too deep in the implementation so that we can have a better visibility on what has to be done
(not related to the PR itself though)

Ideally the IBC protocol is relayer agnostic so using hermes or gorelayer implementation should not matter unless we change the semantic for cronos which may raise some concerns (which could be discussed in the ADR)

Ideally the IBC protocol is relayer agnostic so using hermes or gorelayer implementation should not matter unless we change the semantic for cronos which may raise some concerns (which could be discussed in the ADR)

@mmsqe need to patch the relayer to let it send evm tx instead of cosmos tx.

Ideally the IBC protocol is relayer agnostic so using hermes or gorelayer implementation should not matter unless we change the semantic for cronos which may raise some concerns (which could be discussed in the ADR)

@mmsqe need to patch the relayer to let it send evm tx instead of cosmos tx.

sorry that I am not so familiar with rust.

@mmsqe need to patch the relayer to let it send evm tx instead of cosmos tx.

Could it be done without changing the relayer implementation?

something like

Relayer send cosmos txs -> Cronos middleware catch the cosmos txs and wrap it to an evm txs using module private key

in a general way, if the concern is to generate the receipt for cosmos txs, I think execution is not needed but we could refactor ethermint (https://github.com/evmos/ethermint/blob/main/x/evm/keeper/msg_server.go#L92) to be able to generate more easily receipts out of an eth txs

@mmsqe need to patch the relayer to let it send evm tx instead of cosmos tx.

Could it be done without changing the relayer implementation?

something like

Relayer send cosmos txs -> Cronos middleware catch the cosmos txs and wrap it in an evm txs using module private key

can you elaborate? by middleware do you mean a rpc service? it can convert the original tx to an evm tx, but can't re-sign the evm tx using the relayer's key, right?

But we might can develop a standalone convert and resign cli, which can runs together with relayer and access the same keystore, so we don't have to modify rust and golang version twice. but still need to make some changes to the relayer.

in a general way, if the concern is to generate the receipt for cosmos txs, I think execution is not needed but we could refactor ethermint (https://github.com/evmos/ethermint/blob/main/x/evm/keeper/msg_server.go#L92) to be able to generate more easily receipts out of an eth txs

there are many things to emulate: tx list in eth_getBlock, tx body in eth_getTransaction, and in the end, we can't emulate the v,r,s signature in tx body.

can you elaborate? by middleware do you mean a rpc service? it can convert the original tx to an evm tx, but can't re-sign the evm tx using the relayer's key, right?

I mean ibc middleware, or it can even be done in the ante handler if we want to generalise to all cosmos txs

Yes, the evm txs will be signed by an arbitrary key (module key in genesis config) not the relayer key
but I think it is not too important (maybe?) because :

• In case of ibc, what trigger the "change of state" is the relayer, not the original ibc sender and in most of the case, we don't care about the relayer identity (the from field would be irrelevant in most explorer)
• If we need to get the relayer address, we can add an ethereum event that will specify it so that it will still be possible to get the original cosmos signer from the explorer, as well as the original ibc sender if needed

there are many things to emulate: tx list in eth_getBlock, tx body in eth_getTransaction, and in the end, we can't emulate the v,r,s signature in tx body.

I think we can wrap the cosmos txs in the evm txs like putting the cosmos txs encoded in the call data
v,r,s signature in tx body will be generated by the module private key

But in some case, we may need to also have the ability to generate "custom" ethereum events which make a bit complex.

I mean ibc middleware

do you mean broadcast a new tx in the ibc middleware? that is part of the state machine.

do you mean broadcast a new tx in the ibc middleware? that is part of the state machine.

One step is to refactor ethermint to make it easier to generate ethereum receipt.

I understand that it is a bit complicated now because its all across many different place. But from my understanding the ethereum receipt information is stored in the cosmos events in many places and reconstructed in the rpc endpoints.

It may be possible to refactor the code to have an utility function to generate receipt.
(its basically the same as executing ethmsg except that we can ignore the applymsg part)

but maybe there is more complexity (?), I havent look too deep into the code

do you mean broadcast a new tx in the ibc middleware? that is part of the state machine.

One step is to refactor ethermint to make it easier to generate ethereum receipt.

I understand that it is a bit complicated now because its all across many different place. But from my understanding the ethereum receipt information is stored in the cosmos events in many places and reconstructed in the rpc endpoints.

It may be possible to refactor the code to have an utility function to generate receipt. (its basically the same as executing ethmsg except that we can ignore the applymsg part)

but maybe there is more complexity (?), I havent look too deep into the code

even if we emulated the events, there are still some difficulties, for example getBlock filter evm txs by msg type and result code, now it need to look into the event list of every tx, and in the end we still can't make the signature of the emulated tx.

another possible flow is

cosmos tx -> middleware convert to eth tx signed with module private key -> execute the eth tx as a specific precompile (we may be able to bypass signature verification check and set direction From to original cosmos sender)

at the end we can get the correct tx result code and gas used in the receipt.

but not sure if its possible to change to bypass the signature verification without any risks?

another possible flow is

cosmos tx -> middleware convert to eth tx signed with module private key -> execute the eth tx as a specific precompile (we may be able to bypass signature verification check and set direction From to original cosmos sender)

at the end we can get the correct tx result code and gas used in the receipt.

but not sure if its possible to change to bypass the signature verification without any risks?

I guess ibc incentivization feature rely on correct signer of the tx.

Codecov Report

Merging #1014 (69c3355) into main (2e10beb) will increase coverage by 1.82%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1014      +/-   ##
==========================================
+ Coverage   46.60%   48.42%   +1.82%     
==========================================
  Files         105       73      -32     
  Lines        7884     6125    -1759     
==========================================
- Hits         3674     2966     -708     
+ Misses       3843     2846     -997     
+ Partials      367      313      -54